home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000205_news@columbia.edu _Wed Jun 5 08:47:04 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id IAA08217 for <kermit.misc@watsun>; Wed, 5 Jun 1996 08:47:03 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id IAA04260 for kermit.misc@watsun; Wed, 5 Jun 1996 08:47:01 -0400 (EDT)
  4. Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!news.exodus.net!news.alt.net!news1.alt.net!news.aros.net!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Kermit arp problem
  8. Message-ID: <1996Jun4.100121.81461@cc.usu.edu>
  9. Date: 4 Jun 96 10:01:21 MDT
  10. References: <31b3b0e4.8632940@news.onramp.net>
  11. Organization: Utah State University
  12. Lines: 26
  13.  
  14. In article <31b3b0e4.8632940@news.onramp.net>, saleh@onramp.net (Saleh W. Igal) writes:
  15. > In <4ndec3$skd@epx.cis.umn.edu>, mill0440@gold.tc.umn.edu mentioned a
  16. > problem with arp using Kermit's protocol stack on ODI -- I'm seeing
  17. > almost exactly the same thing.
  18. > 
  19. > Kermit tries to arp the default gateway, but eventually claims that it
  20. > can't arp resolve it and gives up.  I put a protocol analyzer on the
  21. > wire, with this sequence of events:
  22. >    Kermit machine:  ARP resolve 192.238.56.250
  23. >    Default gateway: ARP resolution -- MAC address is XX:XX:XX:XX:XX:XX
  24. >    (waits around 0.25 second)
  25. >    Kermit machine:  ARP resolve 192.238.56.250
  26. >    Default gateway: ARP resolution -- MAC address is XX:XX:XX:XX:XX:XX
  27. >    (waits around 0.25 second)
  28. ---------
  29.     We just went through this exercise.
  30.     Which version of MSK, please?
  31.     To repeat, if MSK version is 3.14 and the boards on both ends of
  32. the connection are from the same vendor and have the same first three bytes
  33. of their MAC addresses alike then there can be a failure (bug in MSK). If
  34. true then please contact me directly at jrd@cc.usu.edu, else let us know
  35. more details, endif. Don't forget that MSK 3.14 will ARP for its own IP
  36. address twice as protection against IP address collisions.
  37.     I gather from your description that Bootp was successfully carried
  38. out, which means a UDP/IP transfer occurred both ways. Is that correct?
  39.     Joe D.